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Scripting code may present maintenance problems in the long run. There is, then, the call for method¬ 
ologies that make it possible to control the properties of programs written in dynamic languages in 
an automatic fashion. We introduce Lucretia, a core language with an introspection primitive. Lu¬ 
cretia is equipped with a (retrofitted) static type system based on local updates of types that describe 
the structure of objects being used. In this way, we deal with one of the most dynamic features of 
scripting languages, that is, the runtime modification of object interfaces. Judgements in our systems 
have a Hoare-like shape, as they have a precondition and a postcondition part. Preconditions de¬ 
scribe static approximations of the interfaces of visible objects before a certain expression has been 
executed and postconditions describe them after its execution. The field update operation compli¬ 
cates the issue of aliasing in the system. We cope with it by introducing intersection types in method 
signatures. 


1 Introduction 

Dynamic languages optimise the programmer time, rather than the machine time, and are very effective 
when small programs are constructed |[T3l fTTl . The advantages of the languages that help in develop¬ 
ment of short programs can be detrimental in the long run. Succinct code, which has clear advantages 
over short-term programming, gives less information on what a particular portion of code is doing (and 
figuring this out is critical for software maintenance, see mmy As a result, productivity of software 
development can be in certain situations impaired ifT^ . In particular, strong invariants a programmer can 
rely on in understanding of statically typed code are no longer valid, e.g., the type of a particular variable 
can easily change in an uncontrolled way with each function call in the program. 

Still, systems that handle complex and critical tasks such as the Swedish pension system ifThl . de¬ 
veloped in Perl, are deployed and maintained. Thus it is desirable to study methodologies which help 
programmers in understanding their code and keeping it consistent. To this end, retrofitted type system^ 
may be an approach to bridge the gap between flexibility and type safety. 

Our proposal is a retrofitted type system for a calculus with a reflection primitive. Our type system 
handles one of the most dynamic features of object-oriented scripting languages, the runtime modifica¬ 
tion of object interfaces. In particular, the runtime type of an object variable may change in the course 
of program execution. This feature can be tackled to some extent through the introduction of a single 
assignment form for local variables. Still, this cannot be applied easily to object fields. On the other 
hand, the information that statically describes the evolution of the runtime type of a variable cannot be 
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locations 

Loc 9 

1 


variables 

Var 9 

x,y : 

:= (identifiers) 

value names 

VNames 9 

z,w : 

'.= x \ 1 

field names 

Fnames 3 

n^m : 

:= (identifiers) 

constants 

Consty 9 

c : 

:= (literals) 

function value 

FVal 9 

V/ : 

:= func(xi, • • • ,x„){e} 

values 

Val 9 

V : 

■=c\Vf\l 

function expressions 


: 

:=x\vf 

atomic expressions 


a : 

:= V z 

expressions 

Expr 9 

e : 

:= a opn{ai,--- ,a„) 
new a.n \ai.n = a 2 
\etx = ei in ^2 
if (a) then e\ else ^2 

1 ef{ai,--- ,a„) 
ifhasattr {a,n) then ei else C2 

objects 

Ob] 3 

o : 

:= {} 1 {Lf} 

fields list 


Lf : 

:= n:v\ n:v,L 

stores 

Heaps 9 

a 

:= ■ 1 il,o)o 


Figure 1: Abstract syntax 


just a type in the traditional sense, but must reflect the journey of the runtime type throughout the con¬ 
trol flow graph of the program. However, it would be very inconvenient to repeat the structure of the 
whole control flow graph for each variable in the program. It makes more sense to describe the type of 
each variable at program points which are statically available and this is the approach we follow in this 
paper. In our calculus, a variable referring to an object is annotated with a type variable paired with a 
constraint expressing an approximation (a lower bound) of the actual type of the object. Our type system 
design draws inspiration from the work on type-and-effect systems ifTTl l6l IH. We present our typings 
in a different manner, i.e., one where an effect is described by two sets of constraints that express type 
approximations before and after execution of an instruction. The sets of constraints together with the 
typed expression can be viewed as a triple in a Hoare-style program logic. 

An important element of the language design is the way functions (called methods in object-oriented 
vocabulary) are handled. The function types describe contracts associated with the functions. We ob¬ 
tained a satisfactory level of flexibility of function application due to type polymorphism. We use two 
kinds of polymorphism here that serve two different purposes. The first one is the parametric polymor¬ 
phism, similar to the one of System F. Through universal quantifier instantiation we make it possible to 
adapt the function type to different sets of parameters. The second one is a form of ad-hoc polymorphism 
obtained through the use of intersection types Q and its purpose is to provide particular contracts that 
are for specific aliasing schemes, i.e., one may describe additional possible behaviours of a function that 
cannot be described by instantiation of a universal type. 

2 Overview of the Calculus 

The syntax of our calculus is depicted in Figure The elements of the set VNames = VarU Loc are 
called value names. The calculus is object-based and our objects are records of pairs fieldname:value. 
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(Let-Propag) 

if ( 7 ,ei <y\e[ then a, letx = ei in 62 ^ cr', letx = e[ in 62 

(Let-Reduce) 

(J, let X = V in e (J,e[x := v] 

(Op-Eval) 

( 7 ,op„(vi,--- ,V„)^ a,5„{opn,Vi,--- ,Vn) 

iH 

a,func(xi,-- - ,x„){e}(vi,-" ,Vn)^ a,e[xi := vi,--- ,x„ := v„] 

(If-True) 

(J, if (true) then 62 else 63 0,62 

(If-False) 

a, if (false) then 62 else 63 ff,e3 

(Ifhtr-True) 

( 7 , ifhasattr (/,«) then ei else 62 (y,ei when a G dom(a(i)) 

(Ifhtr-False) 

a, ifhasattr {l,n) then e\ else 62 o,e2 when a f dom((7(f)) 

(New) 

(j, new^ (/,{})(!, 1 1 fresh 

(SetAtti') 

a,l.n = g[1 := G{l)[n := v]],v 

(GetAttr) 

a,a{l){n) when n S dom((j(/)) 


Figure 2: Semantic rules of Lucretia 


Moreover, it is imperative, that is, it has side-effects, therefore we have a heap where objects are stored. 
Methods are modelled by fields containing functions. There is no built-in concept of self, but it can be 
encoded (see the examples in Section [^. Values are either constants, functions, locations (the latter do 
not appear in source programs, only in the semantics). 

Expressions include value names, primitive operation application, an object creation operation, field 
access, field update, lef-assignmenf, funclion application, a condifional expression, an infrospecfion- 
based condifional expression checking if a certain field belongs fo an objecf. 

The operafional semantics is presented in Figure]^ The construcl let is fhe only possible evaluation 
confexf of fhe calculus, and rule (Lef-Propag) lakes care of fhe propagation of fhe reduclion, while (Lef- 
reduce) performs fhe appropriafe subslifufion of fhe compufed value v, once fhis is obfained. Rule (Op- 
Eval) applies fhe semantical counferparf of fhe operation symbol fo fhe given argumenls. Rule (jS,,) is 
the call-by-value function application. Rules (If-True) and (If-False) are self-documented. Rules (Ifhtr- 
True) and (Ifhtr-False) check whether a certain field belongs or nol fo an objecf allocaled in fhe heap, 
and choose a compulation branch accordingly. Rule (New) allocales a fresh address in fhe heap. Rule 
(SelAllr): eilher adds fhe field n fo fhe objecf allocated al locafion I, initialised wilh value v, if n does nol 
exisl in fhe objecf; or updales n wilh v, olherwise. Rule (GelAllr) exlracls fhe value of fhe field n from 
the object at location I, if n belongs to the object. Note that the semantics is deterministic. 

The usage of an object field depends on ils lype, and since fhe lype clearly depends on fhe compu- 
lalion flow, we need fo update fhe conslrainls via sialic analysis of fhe compulation flow; fo keep Irack 
of fhe knowledge aboul fhe currenf fieldsel, we use judgemenfs which are a combinalion of usual lyping 
judgemenfs, and Hoare-slyle friples: 'Ti;r h e : f;'T 2 . where 'T, are consfrainf sefs representing lype 
information aboul fhe objecls in expression e, respectively before and afler considering fhe effecls of ex¬ 
pression. We call Ihem fhe precondition and fhe postcondition. The lype informalion associated wilh an 
expression is, fhen, a combinalion of fwo ifems: a represenfalion of ils aclual lype and a sel of conslrainls 
on objecls in fhe relevanl pari of fhe heap. 

New fields can be added dynamically fo our objecls, moreover any existing field can be assigned 
wilh values of differenl fypes during fhe compulalion, as if happens in dynamic languages (e.g., Pyfhon, 
JavaScripl, Ruby). An objecf lype, fhen, is nol fixed once and forever. We decided, Iherefore, fo lype an 
objecf wilh a constrained lype variable, wriflen X <# {WTq}, describing some lype informalion for fhe 
listed fields of an objecf of lype X (we write a for a sequence at). 
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Constr 3 h (int,bool,str,...) Yt^X 

TypeSc 9 tc : 

•— tf \ tf f\tc 

Typesy 9 tf : 

:= [f;'F]^[i;'F] 1 VX.ty 

Types 9 : 

> 

II 

Typesa 3 q : 

'll 

< 

Rees 3 r : 

:= {n-.q}\{} 

Constr 3 'F : 

:= X <# 0 


Figure 3: Types 


One group of challenges in the design of the type system is posed by forks and joins in the control 
flow. Consider, for instance, 

if {b) then x.n = 1 else.r.n = ’’hello” 

Statically, we do not know whether ;c has field n of type int or of type string. To keep track of both 
possibilities, we introduce union types: we type .r with type X, where X <# {n : int V string}. Another 
example is if (b) then x.n = 1 else 0: statically, we do not know whether x has field n, but if it does, it 
is of type int. To be able to track the possible absence of a field, we introduce a bottom type: we type 
X with type X, where X <# {n\ int V _L}. Moreover, the constraint X <# {n\ _L} means that the field is 
definitely absent. 

Field access is allowed only if the types indicate the field is definitely present; we can then check 
whether x has field n as in 

ifhasattr (x,n) then x.n + 1 else 0 

to decide whether it is possible to access n or not. 

We use intersection types to capture possible different aliasing scenarios (cf. Section [^. 

2.1 Types 

The syntax of types is shown in Figure]^ We use an abbreviation {m : u,r} for {m : u,n\ q} where 
r = {WTq\, m 0 n. We impose additional, natural restrictions on the shape of the records and constraints. 
We require that in a record of the form {n : q} the labels in n are unique. For a constraint 'F = X Kttrwe 
require that r G Rees and that the variables X are also unique. 

The shape of all types but function types is self-explanatory. A function type is made of: domain 
information, that is, the type of its arguments and a set of constraints that can be read as preconditions 
to the function application; and codomain information, the return type and a set of constraints which are 
the postconditions holding after the function body has been executed. 

We say that m G dom({n : q]) when m is an element of n. Similarly, we say that Y G dom('F) when 
'F = X <# r and F is one of the elements of X. We define the set of free variables FTV('F) in a set of 
constraints 'F so that when 'F = X <# we have X G FTV('F), FTV(r) C FTV('F) and FTV('F') C 
FTV('F). Moreover, we consider V to be a binding operator so that FTV(VX.f) = FTV(f) — {X}. 

Judgements are of the form 'Fi; F h e : f; ^^ 2 , where e is an expression, t is a type, F is an environment, 
and 'Fi and ^^2 are type variable constraint sets, as described earlier. 

We use type variable renaming, indicated with 0, to adapt universally quantified types to different 
situations they can be used in. 

Its formal definition follows. 












M. Benke, V. Bono, A. Schubert 


69 


Definition 1 (Renaming) A bijection Q \ ^ ^ W where ^ is a finite subset of Var is called 
renaming. Wfe extend it structurally to types, expressions, environments and constraints with avoiding 
name clashes for bound variables. We use the notation dom(0) = ^ and img(6) = When sequences 
X,Y of unique variables have the same length we write [X := Y]for a renaming G such that 6(Xi) = Yj 
forXi G X. We assume that d{Z) = ZforZ 0 X. We apply [X := 7] as a suffix, i.e. t\X := 7] = Q{t). We 
write A || G when An {img{G) — dom(6)) = 0. 

Observe that these renamings, unlike type instantiation in System F, cannot substitute two universally 
quantified variables with the same variable. This is an important design choice as we believe that the 
form of types should not hide other information. The standard convention that makes it possible to glue 
together two different variables puts on type readers the burden of checking if different uniting schemes 
do not lead to unexpected situations, that is, unexpected aliasing, in our case. 

2.2 Weakening Woes 

Since the type information changes with the control flow, a constraint update operation plays a central 
role in our system. For compositionality, the following “knowledge monotonicity” with respect to the 
constraint update operation must hold. 

Monotonicity principle For every set of constraints *F and derivable judgement *Fi;r h e : t\W 2 , such 
that variable names for objects created in e are fresh with respect to *F, we can derive 

W ^Wur\-e:f,W 


Intuitively 'F 'Fi means the set of constraints 'F is updated with constraints from 'Fi; it is formally 
defined in Figure 

We observe that our conditional typing rules must have the same postconditions for the two branches 
(see rules (if) and rule (ifhttr) in Figure [^. In Hoare logic, equalising branches’ postconditions is 
obtained via weakening, which in our case might be formulated more or less like this: 

'Fi;rhe :t;'F' 'F''I' 

'Fi;rhe:f;'F 

where *F' 'F means that *F is weaker than *F'. We need, however, to be careful that weakening obeys 
monotonicity, lest the system be unsound (we have the scars to show for it). 

One example of weakening pitfall is forgetting a constraint, i.e.: 

'F,X <#rAcW 

Let’s say we can infer 

X <# {};r h x.m = 1 : int;X <# {m : int} 

Forgetting the constraint would allow us to infer 

X <# {};r h x.m = 1 : int;0 

while monotonicity with W = X <# {m: str} requires that 

X <# {m: str};r h x.m = 1 : int;X <# {m : str} 


which is not sound. 
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Where an object with some fields is required, an object having these fields and also some ofhers 
is allowed, according fo fhe Liskov subsfifufion principle ifTOl . One way of achieving fhis would be 
allowing weakening by forgeffing fields: 

X <# {m : u,n : q} X <# {n : q} 

Alas, fhis is nof sound eifher, since if allows fo infer X <# {};r h x.m = 1 : int;A <# {} and, by mono- 
fonicify, 

X <# {m: str};r h x.m = 1 : int;A <# {m : str}. 


This hinfs fo fhe facf fhaf our (defined over relation <#) does nof coincide wifh subfyping. Subfyping 
(af leasf in widfh) is nevertheless essenfial in an objecf-orienfed setting and we acfually permif if in 
funcfion calls (see fhe explanafion abouf rule (fapp) in Secfion 2.3 and examples in Secfion|^. 

Equalising branches’ posfcondifions mighf be done using union fypes: if an affribufe has fype fi affer 
one branch, and t 2 affer fhe ofher, we say if has fype 0 V t 2 - However, we need fo fake special care; when 
frying fo handle fhe case where an affribufe is sef in one branch of fhe condifional, e.g., 

if (b) then x.m = 1 else 0 


if may be fempfing fo use a weakening schema similar fo 

{n : t} {n ■ t,m : u\/1.} m^n 
This fums ouf fo be unsound, too, as shown by fhe following: 
func(x) { ifhasattr (x, m) then x.m + 1 else 0} 

Using fhe weakening schema above, we can give if fhe fype 

[Z;A<#{}]^[int;A<#{}] 

whereas calling fhis funcfion wifh an argumenf confaining field m : str leads fo a crash. 

Therefore we propose a nofion of fype weakening as formulafed in Figure]^ This allows us fo avoid 
fhe piffall presenfed previously and give fhe funcfion mentioned fhere a correcf fype 

[X',X <# {m : _L}] ^ [int;X <# {m : _L V int}] 

which ensures fhaf fhe field m is absenf from ifs argumenf. 


2.3 Typing Rules 

The fyping rules of our sysfem are presenfed in Figure]^ A freshly creafed objecf has no fields, hence 
fhe form of rule (new). We impose an injecfive map from fhe sef of fype variables presenf in fhe program 
fo memory locations, fherefore fhe fype variable needs fo be fresh. The consequence is fhaf any relevanf 
fype variable occurring in fhe posfcondifion, buf nof in fhe precondition of a judgemenf, refers fo an 
objecf creafed wifhin fhe expression under considerafion. More precisely, whenever 

'Ti;rhe:f;'T2, X e dom('T2)\dom('Ti,r) 

X is fhe fype of an objecf creafed wifhin e (or phanfom). Then we also know fhaf all ifs fields nof 
menfioned in fhe posfcondifion for X are definifely absenf, which is why fhe rule (bof) is sound. 

Rule (ace) governs field access. A field is accessible from an objecf (value) if fhe field’s fype is a 
fype belonging fo fhe sef Types. Infuifively, a field can be accessed only if ifs fype does nof confain fype 
_L, fhaf is, fhe field is acfually presenf in fhe objecf. 
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qdicq 


(^erfl) 


q^cqyq' 


(^erV) 




(^crrfl) 


0 0 


{■<c crfl) 


qi die qi qi d^c 73 
q\ q 3 


(^c trns) 


‘Pi 'P 2 
X ^ FTV(‘Pi) 

'Pi ^c'i‘2,X<#r 


{die cevlv) 


qdcq' {n ■ u} dc {n : «'} 

{b : q,n : u} dc {b ■ q',n : m'} 


ridcri 'Pi^c'P2 

X^FTV('Pi,'P2) 

‘Pi,X<#n ^c'P 2,7^ <#r2 


(dc estret) 


Figure 4: Order over constraints 


Record update 

r ^ {} = r 


{a : u,r} ■<r^ {a : u'} = {a : u',r} 


{n : q} ^ {a : u'} = {a : u',n : q} if a 


r ^ {a: u” ,r'} = (r ^ {a : u”}) ^ r' 

Constraint update 

>P^0 = ‘P 


<#r^X <#r' = <# (r ^ r') 

<# r ^ <# r' = (T ^ '¥'),X <# (r ^ /) 

'i' ^^",X <#r' = {^‘ ^^"),X <#/ if X^ dom(T) 


Figure 5: The update operation 


Rule (updt) describes field update and works whether the field m is already present in the object or 
not. The postcondition is updated accordingly, by using the operation from Figure The constraint 
related to X in the postcondition will record either the presence of a new field, or the (possible) change 
of type of an already present fields (notice that most of the rules defining are for the propagation of 
additions/changes and for bookkeeping). 

The let instruction provides a form of sequencing and the rule (let) types it accordingly. We use the 
following notation: 

letx = e;es ^\etx = e 'm es 
e\ es I—)■ let _ = e in 

Rule (fdcl) types a function declaration. It checks the body against the given preconditions and 
postconditions, moreover the type is generalised on all possible type variables not appearing in the typing 
context r (in an ML-style). This is done to abstract from the choices of type variable names in types of 
the objects passed as arguments, as well as objects created in the function body, while protecting the type 
variables referred to by nonlocal identifiers. 

The process of mafehing formal and acfual parameters and preconditions can be seen in the rule 
(fapp). This rule, given a well-typed function declaration: (/) checks the actual parameters against the 
formal parameters’ types; (//) checks that the state at the call site (described by *T) ensures the callee 














Lucretia 


x0FTV(>y,r) 

'P;r,z:?hz:f;'F(var) 'F;rh new :X;X <#{},'F 

^\\T \- e \ t\X <# {n : u },^2 
X0FTV('Fi,r) m^n 

'P; r h c : fc; 'F (const) ^iX'r e ■.f,X <# {nru,m\ l.],^2 

'P;rhci ^>uT^e2:t2-^>2 

t\J 2 bool yinty real t = t\yt 2 

'P;rhz:X;'P 

^>3X<#{m-.t,rPrq} 'P;rhzi:X;'P »F;r h Z 2 : t;*!" . 

^>■,Ty zi.m = Z2-f,^ ^X <# {m-.t] ’ 


^uVy ei-.ti ,^2 a:bool-,^ 

^> 2 -,T,x-.hyeo-.t -^>2 for/=1,2 

*Pi;ri-letx = Cl in Co : *F;ri-if (a) then ci else ^2 : 

- f;rh.:,;r, -^itlFhTTTvp^ 

X = FTV(^'F„t,'F,)\FTV(r) 

*P;ri-func(x){e} : f/;*F 

0 : X —)■ y is renaming FTV(ty) || 6 

FTV('F) n (dom(0 ('F,)) - dom(0 ('F,))) = 0 
'y;rhw: e( 5 );'y 

'y dom(0('y,)) cdom('y) 

'y;rhc/(w) :0(r);»y^ei(»y,) 

'y;rha:X;'y 

'y;rhfunc(^){c} ^>[X {n}]-r^ er-f ,^2 

'y;rhfunc(x){c} :i 2 ;'I' ^[X {n}]-rh 62 : f,^2 

*y;r h func(x){c} : ii At2;*I^ ^ *y;r h ifhasattr (a,n) then ci else C2 : ^ ^ 

'y;rha:X;»y ^•;r F e, : l;^'2 

^uryz:hAt2;^2 >y[x^*W]=>y *£{+,-} 

*yi;r h z : t,;*y2 *y;rh ifhasattr (a,n) then else e_ : t;*y2 


(ifhttr) 


Figure 6: Typing rules 
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In the following * should be understood as any of + and : 

('P,X <# r)[X {fl}] = <# {r[X {a}]) 

'i'lX {a}] = 'P when X ^ dom(‘P) 

{a : t,n : q}\X {a}] = {a : ,n : q} 

{a : t,n : q}\X ^ {a}] = {a : J-,n : q} 

(f)+= f for f e Types (fV_L)^=f^ 

Figure 7: Definiteness update 'F[X + {a}] and 'F[X {«}]■ 


precondition (*Fi). Note that this is expressed in terms of updates, because each declared function can 
be seen as a state updater, as well as inclusion of domains, because the precondition cannot introduce 
new type variables (that directly correspond to locations on heap). All checks here are done modulo 
a renaming 6 of type variables establishing a one-to-one correspondence between formal and actual 
arguments and preconditions, which is formally expressed with the || operator. The other side condition 
ensures the type variables chosen for the objects created by the function are fresh. Finally, we stipulate 
that the result type is the formal result type with type variables renamed according to 6, that adapts the 
type of the function to the site of the function call. The final sfate corresponds here to the initial state 
updated according to the callee postcondition 'F,. 

Renaming is also an instrument we use to deal with aliasing and works together with intersection 
types and their related rules, (lA) and (EAi). See the example in Section]^ for an account on how 
renaming and intersection types work to deal with aliasing scenarios. 

Rule (ifhttr) types an introspection expression against two different sets of constraints, assuming the 
presence (resp. absence) of the attribute n. The rule (ifhttr*) is a special case applicable if presence of n 
can be determined statically. 

3 Expressivity of the System 

Let us now look at some examples that illustrate the strength of the type system we propose. 

An interesting point is what happens when an object is modified and/or created inside a conditional 
instruction. We present four examples: one where the same attribute is set in both branches, one where 
the assignment happens in one branch only, one in which an object is created and assigned to a field in 
one branch only, and one where object creation happens in both branches. We assume we have a variable 
called hasarg of type bool and a variable called arg of type string. 

Setting the same attribute in both branches. Consider the code. 

let X = new in 

// x:A;A <#{} 

if (ha) then x.m = a else x.m = "help" 

// X : A;A <# {m : string} 

We can type this example as follows: 

*Fi;ri h /jfl:: bool 
'FpLi h x.m = a : string ;*^2 
'Fi;ri h x.m = ’’help” : string;*!^! 

*Fi;ri h if {ha) then x.m = a else x.m = ’’help” : string;*F2 
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where 


Note that *^2 = 


Fq = {ha : bool,a : string} 

Fi =Fo,x:X 
=X <#{} 

'i '2 = X <# {m : string} 

’ X <# {m: string} and, by using the (updt) rule, we can derive 
'Fi;Fil-v:X 'Fi;Fi h 5 : string 


*Fi;Fi h x.m = s : string;*^2 

for 5 = a as well as ^ = ’’help”. 

Setting an attribute in one branch only. Consider the code. 

let X = new in 

// x:X;X <#{m:X} 

if (ha) then x.m = a else "" 

// X ; <# {m : string V_L} 

Typing the then branch looks like: 

*Fi;Fi h x.m = a : string; X^ <# {m : string} 


'Fi;Fi h x.m = a : string; X <# {m: string} 
[m : string} {m ■ string V _L} 


'Fi;Fi h x.m = a : string; *^2 
Typing the else branch looks like: 

string string V_L {} {} 

[m : L} {m ■ string V L} 


( 1 ) 


; h ”” : string; X <# {m: string V _L} 
Then, by putting the two branches together, we get: 

'Ti;Fi h/ra: bool;'Fi (1) (2) 


( 2 ) 


'Ti;Fi h if {ha) then x.m = a else ”” : string; *^2 


where 


Fq = {ha : bool,a : string} 

Fi =Fo,x:X 
= X <# {m : _L} 

'i' 2 = X <# {m : string V _L} 

To type the whole let we need to derive 

h new :X,X <# {} 
h new : X,X <# {m : _L} 

which is easily done using the (new) and (hot) rules; the side-conditions of (hot) are obviously respected 


here, however they are needed to prevent the problems with weakening described in Section 2.2 
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Creating an object in one branch only. Let b be of type bool, and x an object not containing field a. 
Consider: 

if b then 

x.a = new; 0 
else 0 

Typing the then branch (with type Y for the new object) looks like: 

*T;r h x.a = new;0 : int;Y <# {a :Y},Y <# {} 

*T;r h x.a = new;0 : int;Y <# {a : F V _L},F <# {} 

by applying rule (cnstr ^c), with T = {b '. bool,;c: X}, 'Y = {X <# {a : -L}}. 

Similarly, for the else branch we want to prove 

'T;rhO: int;X <#{a:FV_L},F <#{} 

We can easily infer *F;r h 0 : int;*F. Using rule {Ac cevlv) we get 

X<#{a: T} <#{a : T},F <# {} 

Then with some applications of Ac bookkeeping rules we can get 

'T^cY<#{a:FV_L},F<#{} 

which leads us to the desired conclusion. 

Function declaration and application. Consider a function that adds a field 
named m wifh a value provided as ifs second argumenf (of an arbifrary fype 
t) fo an objecf being ifs firsf argumenf: 

func{self,x) { self.m = x } 

Lef tadd = yXs.[Xs,t',Xs <# {}] [t;Xs <# {m : t}]. Observe now fhaf fhe fype 
ensures an imporfanf properfy of fhe objecf graph in fhe heap fhaf holds each 
time fhe function is called, fherefore if is invarianf. The fype VX.[... ;*Ti] 

[...; *^ 2 ] may be read as “for all graphs such fhaf holds before fhe call, *^2 
holds afterwards”. In Figure 7, fhe boxes represenf objecfs in fhe heap and 
have names {Xs,t) fhaf stem from fhe fypes. In addifion fhey are marked wifh 
variables fhaf reference fhem {self ,x). The scribbles in fhe boxes hide fhe fypes fhaf such an objecf can 
assume during fhe compufafion. The inifial inpuf graph does nof have an explicif connecfion befween Xs 
and t, buf in fhe resulf fhere is such a connecfion, from fhe now explicif field m to t. This is a simple 
example, buf fhe invarianfs in real programs may involve complicafed graphs fhaf can be expressed 
sfraighfforwardly in fhis way. 

We can derive by rule (fdcl) 

self : Xs,x : t\Xs <# {} h self.m = x : t\Xs <# {m : t} 

Y<lunc{self,x){...]-.tadd,^ 

Now we apply fhe above function fo a newly creafed objecf: 

let init = func{self,x) { self.m = x } 
let o = new // o ; Xo; Xo <# {} 
init ( 0 , 42 ) // o ; Xo; Xo <# {m:int} 


Inpuf: 


self: ^ 

x; 

0 ^ 

Oufpuf: 

|yI 




Figure 8: Graph frag- 
menfs for inpuf and ouf- 
puf of fhe function fype 
in fhe example. 
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The renaming 0 connects the formal and actual parameters, sending Xg to Kg', putting 

To = {o : Xo', init : tadd}, * 1^0 = i'fo <* {} 

We can infer, by (fapp), 

*To; To h init{o,42) : int; *To <* {fn : int}) 

Here, we can see our form of subtyping in width at work (see Section [23] and rule (fapp)); observe 
that the same function may be called on an object containing some fields already: if 'Tq = <# {n\u], 

then 'To <# {}) = 'I^o- In both cases, the renaming is a witness that the program state satisfies 

the function precondition. 

Intersection types. As hinted, the idea behind intersection types in our system is that they capture 
allowed aliasing scenarios. Consider the following function: 

func{x,y) { x.m = 1; y.m } 

This function can work in either of the following scenarios: 

(i) the actual parameter for y has field m before if is passed fo fhe funcfion, 

(ii) fhe acfual parameters for .r and y are fhe same objecf. 

Hence fhe fype of fhe funcfion will be wriffen as ti A t 2 , where t,- represenf types corresponding fo 
scenarios (i) and (ii): 

=VA,F.[A,T;'Ti] ^ ^ X <# {m : \nt}] 

wifh 'Ti = A <# {},T <# {m : u}, and 

f 2 =VA.[A,A;A <#{}] ^ [int;A <# {m : int}] 

In practice one does nol need fo wrife intersection types, buf insfead wrife multiple confracfs for a 
funcfion (and add more as needed), for example (wifh a fair dose of synfacfic sugar): 

f : [X,Y;Y.m:U] => [U;X.m:int] 

f : [X,X] => [int;X.m:int] 

func f(x,y) { x.m = 1; y.m } 


Point, ColorPoint. The following example is an encoding of a paradigmatic example in our system. The 
fype of fhe mv mefhod is a funcfion fype fhaf fakes as a paramefer an objecf confaining af leasf a field x 
of type int. Nofe fhaf Ibis is an imperafive version (wifhouf My Type) of an analogous example in |[5j. 


let o = new; 

o.x= 7; // r= {x:int} 

// Tmv = forall Xs.[Xs,int;Xs<#r] => [Xs,Xs<ir] 
o.mv = func (self,dx){ self.x = self.x+dx; self } 
// o ; Xo; Xo <# { x:int, mv:Tmv } 
o.c = "blue"; 

// o : Xo; Xo <# { x:int, mv:Tmv, c:string } 
o.mv(o,3); // can call mv: Xo <# { x:lnt } holds 
o.c // we can still read the field "c" 


In Ibis example, we again see our subfyping in widfh af work. The mefhod mv requires an objecf wifh a 
field X, buf if works also if fhe acfual paramefer confains exfra fields, in our case field c. Moreover, fhe 
field c is still accessible after fhe mefhod call. 
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4 Conclusions and future work 

Our contribution is a novel type system for typing dynamic languages in a retrofitted manner, with 
particular emphasis over the flow of control and with the aim of tracing the changes of object interfaces 
at runtime. We express this change by means of Hoare-like triples that describe the structure of relevant 
objects before an expression is executed and after its execution. 

The type reconstruction for our system seems undecidable (in fact, a slightly weakened version of the 
intersection type system can be embedded in the language |81). However, there is a strong evidence that 
the type system becomes decidable when type annotations are provided for functions (by a programmer 
or by a non-complete heuristics), as seen for similar annotation schemes fT] . 

As a further development, we would like to apply Lucretia’s approach to regulate control flow in 
JavaScript. Moreover, we want to couple our system with the gradual typing method ||4l|2l[T5l, that sup¬ 
ports evolving an untyped program into a typed one, possibly by using the like-type approach of ifTSll . 
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